Data processing systems such as personal computers, embedded systems like mobile phones or other mobile devices, and other data processing devices depend on the execution of correct software that has not been manipulated in an unauthorised way. Manipulation of the software might lead to incorrect behavior of the device or even a breaking of the fundamental security features of the device. Hence, it is particularly important to protect the core software of the device.
The operation of data processing systems like can be disturbed through malware such as viruses and Trojan horse programs. One way of protecting such user devices from these types of threats is to deploy anti-virus and internet security programs such as offered by companies like Symantec, F-Secure, and E-set. Over the years such protection tools have become very effective to block known (and similar) threats. Through the use of Intrusion Detection System technologies into these tools it is also possible to prevent many other attacks on user devices. Another approach to fight malware is to maintain a so-called “path of trusted software”. Here the basic idea is that all the software that is executed on a device is authentic (and hopefully not harmful). Authenticity of the software is realised by having a secure boot which guarantees that the (basic) system that is loaded into the user's device is authentic, and by then having the system to load only software that is authentic, which may be enforced through the use of digital signatures that each software may be required to carry. An industry standard for realizing secure boot is defined by the Trusted Computing Group (TCG), see e.g. the “TCG Specification, Architecture Overview”, Specification, Revision 1.4, August 2007.
Yet, it remains a problem that, despite the above measures, some attacks may still succeed and affect the functioning of a user device.
The TCG has developed a secure mechanism called attestation by which an external observer system (server) can interrogate the state of the core security engine, referred to as the Trusted Platform Module (TPM), e.g. as described in the “TCG Specification, Architecture Overview” (ibid.) and in the “TPM Main Specification Level 2 Version 1.2, Revision 103.” This process is called remote attestation, and it includes the server receiving a signed value of TPM PCR register state. This allows the remote server to track for example which software was loaded in the user device. However, the above prior art remote attestation, does not provide a secure way for the server or any user device management system to correctly decide and enforce a reboot (restart) of the user device in case a user device is infected by malware.
Virus detection and IDS software will not fully prevent malware from reaching a user device. The use of signed software can be enforced for the standard components of a system (like boot software and OS software modules). For device drivers a strict enforcement is more problematic as it implies, for example, that developers of graphic cards must get their device drivers signed by the OS vendor or user device vendor. For application software the signed software methodology is often considered to be too restrictive for application developers. Therefore one often does not use a chain of trusted software (signatures) and instead uses a user interaction by which the user is requested to give his/her acceptance of this software to be installed on the device. Such an approach is for example used in the Android system for mobile devices. Thus, even in the presence of secure boot solutions such as defined by TCG there remains a need for an improved protection against malware.
The remote attestation function as described by TCG may be used by a device management system to observe the device and to conclude that the device is infected. However, this implies that the trusted part in the user device is capable in observing its full functioning, i.e. is capable of making a decision that it is infected. However, if such an infection has occurred, it was the protection software of the device that had actually failed to block the malware.
In terms of TCG, there is an additional problem in that the core of the protection mechanisms is built around the TPM which is a tamper resistant hardware module that is capable of keeping securely secrets and state variables. However, the TPM is a slave device, i.e. it acts when being instructed to do so. Hence the computation performed by the TPM is driven by the software in the user device, i.e. in case of an infection the computation performed by the TPM is driven by an infected entity. Consequently, when a remote attestation request arrives the malware may put the device back in a seemingly correct state, hide itself, and start to process the attestation request. When the response of the attestation is finalized the malware may then again take control. In the meantime, the management system still gets the indications from the device that everything is ok, although the management system may have indication from other observations that something is wrong with the operations of the device.
U.S. Pat. No. 7,360,253 discloses a method of encouraging a known operational state in a computer. The computer includes a watchdog circuit and executes a monitor system. The watchdog circuit includes a timer, and upon expiry of the timer, the computer is rebooted unless the monitor system sends a message to the watchdog circuit which causes a reset of the timer.
However, it remains a problem that the security of the above prior art method relies upon the monitor system. Hence, if the monitor system is attacked the security of the method may be compromised.